Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.01%. Comparing base (ff61ea0) to head (b8904f3).
⚠️ Report is 9 commits behind head on master.

@@           Coverage Diff           @@
##           master     #582   +/-   ##
=======================================
  Coverage   76.01%   76.01%           
=======================================
  Files          42       42           
  Lines        2468     2468           
=======================================
  Hits         1876     1876           
  Misses        592      592           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

No idea if this is correct, feel free to resolve the security issue otherwise.

No idea if this is correct, feel free to resolve the security issue otherwise.

Isn't this just a false positive, taking into account that this is a transitive dependency of pydoc, and we use pydoc as a dev dependency? Meaning the black is not part of our production package.

Of course, it is completely wrong for pydoc (and its dependencies) to use black (linter & formatter) as a production dependency. But it is what it is...

Security issues in dev dependencies are also valid, because we use them in our CI where we have various secrets that could leak. But you are right that those issues are less important and often invalid for us. Still, if we can resolve them with a dependency bump, we should do so.

What's the alternative here? I guess waiting for pydoc to update their dependencies? We can surely wait a bit with this, I was mostly testing how claude handles this kind of task, since it will get worse once we include more repositories in those checks.

Security issues in dev dependencies are also valid, because we use them in our CI where we have various secrets that could leak. But you are right that those issues are less important and often invalid for us. Still, if we can resolve them with a dependency bump, we should do so.

That makes sense, thanks.

What's the alternative here? I guess waiting for pydoc to update their dependencies? We can surely wait a bit with this, I was mostly testing how claude handles this kind of task, since it will get worse once we include more repositories in those checks.

The issue is that pydoc-markdown, which we use for documentation generation, uses docspec-python to parse Python source code, and docspec-python depends on black for parsing. While docspec-python has already updated to a newer version of black, pydoc-markdown is not very actively maintained and still uses an older docspec-python version, which results in the outdated black.

We can try to resolve this as proposed in the PR by explicitly constraining the black version on our side. Hopefully, this won't break anything in the docs generation.